This invention relates to computer security, and more specifically to a simulator of a reference monitor with which computer security policy is implemented.
Conventional network security systems can be said to provide either passive or active protection from threats. Passive security systems collect data on system activity so that the activity can be analyzed, security breaches can be detected, and access policies can be adjusted over time. Examples of conventional passive security systems include activity logging tools and auditing tools, which may be employed in conjunction with one another. Activity logging tools track the activity of one or more computers and record system activity as entries in a series of log files. Auditing tools typically examine those log entries to discern breaches, attacks, or other potentially threatening activity.
Active security systems provide real-time barriers to intrusions via software- or hardware-based, pre-programmed detection and access prevention measures. Examples of active security systems include content filtering tools and access control and/or monitoring tools. Content filtering tools, such as computer virus scanners, execute on either e-mail servers or workstations, and function by examining incoming content (e.g., e-mail messages and attached files) to determine the presence of threatening matter, by comparing that content with data received in previous attacks. Some access control tools, such as network firewalls, are deployed on dedicated machines at a network perimeter to control inbound and outbound access using pre-configured permission policy. Other access control tools also perform access monitoring functions, such as regulating access to system resources. For instance, reference monitors, which execute in the kernel of a workstation or server, regulate requests that are issued by applications or processes for access to system resources. Some reference monitors are stateful (such as the stateful reference monitor described in commonly assigned U.S. patent application Ser. No. 10/071,328, which is incorporated herein by reference), and function by preventing requests that cause unwanted variations from a dynamic machine state. Other reference monitors are stateless, and function by preventing variations from predetermined system settings.
The rules defining a security system's response to specific activity (i.e., whether the activity is allowed, denied, regulated or otherwise observed) is known as a security policy. It is advantageous to periodically evaluate a security policy's effectiveness in deterring evolving security threats. Evaluating security policy can provide a better understanding of how the security system responds to various stimuli, and allows those responses to be refined if appropriate. It may also present the opportunity to compare the effectiveness of a policy (i.e., its ability to stop harmful activity while yet permitting innocuous activity) to an objective benchmark.
There are two prevalent techniques used to evaluate security policy. The first technique involves gathering a sample “trace” (i.e., log of system activity), and applying the stimuli recorded in the trace to a live or semi-live computer system to determine the computer system's response to the stimuli. A trace includes a series of records embodying requests for access to system resources issued by various applications and processes executing on the system. Examined individually, trace records reveal the access requested by a particular process to a resource. For example, a trace record may show the level of access requested by an e-mail application in a particular circumstance, such as permission to update the system registry. Examined in aggregate, trace records reveal relationships between requests, such as the types of requests that are common across applications, the period that elapses between requests, and other relationships. For example, a group of records may reveal that only certain types of applications request permission to update certain data, or attempt certain operations. As such, trace data can be extremely useful for studying a security system's response to various stimuli, so that the response can be refined, if necessary. A trace may include, for example, access requests issued during a computer virus attack on one system. When the requests in the trace are re-executed on a second system, information produced during the second system's response may reveal whether that response should be adjusted and, if so, how.
A second technique for evaluating security policy also employs trace data, but instead of executing the stimuli recorded therein on a live or semi-live computer system, the data is analyzed by a neural network or other collection of computer programs to determine whether it represents normal and/or harmful activity. For example, a neural network may be used to recognize one or more patterns of access requests within the trace, and to determine whether these patterns represent an attack or other threatening activity. For example, a neural network may be employed to recognize that a group of requests that individually seem innocuous are actually, in aggregate, an attack. This analysis may be performed to identify and catalog known harmful and/or harmless behavior so that the security policy implemented on one or more other systems can be updated accordingly.
There are at least three drawbacks to these techniques for evaluating security policy. The first is that obtaining trace data can be costly (particularly when supplied by a third party provider), and the data obtained may be flawed. For example, because third party trace data is a recording of actions monitored by and executed on another system, the execution of those actions on the originating system may have different effects than their execution on the system being tested. The second drawback is that running a simulation on a live or semi-live computer system consumes valuable computing resources by requiring the computer system to be taken offline, thereby imposing not only the cost of execution but the opportunity cost associated with suspending business functions normally performed by the offline computer. The third drawback is that because a trace may need to comprise a large body of varied stimuli to provide meaningful results, testing can be extremely time-consuming.